Blog

Что Такое RUP и Зачем он Нужен в Вашем Проекте

RUP (Rational Unified Process) - это software development process framework (т.е. шаблон процесса разработки программ). Он был разработан Rational Software Corporation, которую в последствии купил IBM. Хотя сам по себе RUP несколько устарел, — это стандартная и понятная всем основа для организации вашего конкретного проекта. Хотя сегодня существует множество других frameworks (CMMI, ITIL и так далее, включая отраслевые ASPICE, eTom), RUP – это необходимый минимум и структура понятная всем в индустрии. Т.е. пакет документов RUP, особенно из Interception phase (см ниже) позволяет описать ваш продукт/сервис на понятном всем языке и сильно упростить взаимодействие с другими людьми. Шаблоны артефактов RUP на любом языке есть в инете.

RUP построен вокруг четырех основных ступеней (phases), у каждой из которых своя цель:

  • Inception – определить назначение (business case) проекта, его объем (scope) и основные архитектурные характеристики.
  • Elaboration - уточнить требования к проекту, оценить проектные риски и создать подробную архитектуру.
  • Сonstruction - собственно создание программного продукта, с использованием вашей любимой методологии.
  • Transition – запуск готового продукта, его дальнейшая поддержка и корректировка в соответствии с обратной связью от пользователей.

RUP определяете основные понятия:

  • Роль – кто делает и что делает (e.g., analyst, designer, tester).
  • Активность - что нужно сделать, чтобы достичь определенной цели (e.g., use case modeling, coding, testing). Набор активностей с ролями образуют процесс.
  • Артефакт – сущность (work product), которая должна образоваться в результате выполнения процесса.

RUP определяет шесть базовых практик:

  • Итеративная разработка.
  • Управление требованиями.
  • Использование компонентной архитектуры.
  • Визуальное моделирование архитектуры.
  • Контроль качества.
  • Контроль изменений.

Основные артефакты RUP

Для ступени Inception:

  • Vision Document – описывает высокоуровневые требования к системе, ключевые свойства и бизнес-задачи системы, и ее ограничения.
  • Business Case – описывает бизнес-потребности, которые закрывает проект, планируемые источники дохода и основные бизнес риски.
  • Initial Use Case Model - высокоуровневое описание способов использования продукта (Use Cases)
  • Project Plan – высокоуровневый план проекта, описывающий основные вехи, требуемые ресурсы и возникающие ограничения.
  • Risk List– список рисков с оценками их стоимости и вариантов работы с ними.
  • Stakeholder Request List – список всех интересантов (stakeholders) проекта, их ожиданий и требований.

Для ступени Elaboration:

  • Software Architecture Document (SAD) – архитектура проекта, включая выделение требований влияющих на архитектуру (ASR) и обоснование архитектурных решений.
  • Use Case Model – детальные сценарии использования продукта (Use Cases), включающие взаимодействие между разными участниками (actors) системы
  • Supplementary Specifications – описание нефункциональных требований и ограничений, включая регуляции.
  • Iteration Plan – план итеративной разработки, цели и артефакты каждой итерации.
  • Glossary, Roles and Responsibilities – основные термины проекта, роли проекта и их зона ответственности.

Для ступени Construction:

  • Design Model - детальная спецификация дизайна, включая диаграммы классов, диаграммы последовательностей и другие артефакты дизайна.
  • Implementation Model - включает исходный код, описание компонент, инструкцию сборки.
  • Test Plan - описывает систему тестирования включая test cases, test scripts, и acceptance criteria.
  • Deployment Model - описывает архитектуру развертывания включая окружение, инфраструктуру и процедуру развертывания.

Для ступени Transition:

  • User Manual – руководство пользователя.
  • Installation Guide - руководство по установке, настройке окружения и дальнейшему администрированию.
  • Release Notes - список основных особенностей конкретного релиза, включая список известных проблем с ассоциированными рисками.
  • Training Materials - материалы для обучения пользователей, системных администраторов и продавцов.
  • Support Documentation – правила и контакты технической поддержки.

Для всех ступеней (лучше это сделать в начале работы):

  • Change Request - описание формата запросов на изменение и порядка работы с ними.
  • Status Assessment – формат регулярного отчета о состоянии проекта и возникающих проблемах.
  • Configuration Management Plan – описание работы с артефактами проекта, кто будет из подписывать, как они будут версионироваться, архивироваться и так далее.